* feat(editor): Tab inserts 2 spaces inside code blocks (Shift-Tab unindent)

Follow-up to the editor-wide TabFocusTrap: that extension consumes every
fall-through Tab to keep focus from escaping the editor, but that left
code blocks with no Tab handler at all — typing a code snippet had no
way to indent. Authors writing JS / TS / YAML / shell examples hit the
gap immediately.

Tiptap's upstream `@tiptap/extension-code-block` ships a Tab handler that
inserts `tabSize` spaces at the caret (or indents each line of a multi-
line selection) and a Shift-Tab handler that pulls up to `tabSize`
leading spaces from the current line — but both are gated on
`enableTabIndentation: false` by default. Flip it on via `addOptions()`
on the app's `CodeBlockFidelity` extension and override `tabSize: 2` to
match Prettier / Biome defaults across the languages most likely to
appear in OK docs.

Chain order is intentional: `CodeBlockFidelity` runs at priority 60,
`TabFocusTrap` at priority 1. Tiptap calls keymap handlers HIGH → LOW
and stops on the first true return. Inside a code block, the code-block
handler fires (cursor parent type matches) and inserts spaces. Outside
a code block, it returns false and falls through to the trap (return
true, preventDefault, no edit). List items at priority 100 still claim
Tab first inside lists (sink/lift); table cells at priority 60 still
claim it for next/previous cell.

Markdown round-trip: spaces inside fenced code blocks (CommonMark §4.5)
are preserved byte-for-byte through the markdown pipeline, so 2-space
indents inside fences survive a parse + serialize cycle. No fidelity
risk and no schema change.

Two behavioral tests in `shared.dom.test.tsx` mount a real Tiptap
editor with `sharedExtensions` and dispatch real `keydown` events
against `editor.view.dom`:
- Empty code block + Tab → text becomes `"  "` (2 spaces inserted)
- Code block with `    hello` + Shift-Tab → `"  hello"`; again → `"hello"`

Visually verified end-to-end: created a code block, pressed Tab twice,
typed `X` — got `"    X"` (4 spaces + caret marker), confirming each
Tab inserts 2 spaces and the trap doesn't interfere.

* review: fix addOptions typing; update stale e2e gap comment; trim vocab

Three review items on PR #2077.

Major (the actual CI break): `addOptions()`'s return type didn't satisfy
`CodeBlockOptions` because the spread of `this.parent?.()` makes every
field optional, so TS rejected the override. Cast the return value to
`ReturnType<NonNullable<typeof this.parent>>` — `parent` always exists
at runtime for an inherited `addOptions`; the cast just tells TS what
the runtime invariant already guarantees. The earlier non-null assert
attempt was undone by `biome --unsafe`'s `noNonNullAssertion` rewrite.

While You're Here (accepted): `tests/stress/list-keymap.e2e.ts` carried
a stale "Tab-in-code-block unimplemented" gap comment + a `test.fixme`
asserting a literal `\t` insertion. With this PR's `enableTabIndentation:
true, tabSize: 2`, the spec R19(3) `\t` form is no longer what ships —
two spaces is. Updated the gap comment to reflect the shipped reality,
updated the test assertions to look for `first  ` (two trailing spaces),
and kept the `.fixme` because Playwright's keyboard.press('Tab') still
moves browser focus before PM's keymap plugin sees the event (Playwright-
only event-routing quirk, not a product bug). The unit-level contract
in shared.dom.test.tsx already covers the behavior end-to-end via real
Editor mount + real keydown dispatch.

Consider (accepted): dropped "(empirically verified)" parenthetical
from the dispatchKey helper comment in shared.dom.test.tsx per the
comment-discipline rule (process vocab in source).

GitOrigin-RevId: 518f786ee4b2a6fb44c19ac7cbbc4275832001cc